NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/8259

Internet Message Format | 1996-08-05 | 1.8 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c
Subject: Re: const char??
Date: Sat, 02 Mar 96 14:08:50 GMT
Organization: none
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <[e-mail]>
           [e-mail] "Kazimir Kylheku" writes:

>Ah, I see. That makes sense, since strchr() has to manufacture a pointer
>somewhere along the line, through which access to the string s could take
>place. What if it is done immediately in the return statement of strchr()? As
>in:
>
>        return (char *) x;      /* x is (const char *)  */
>
>That's one way to write the function which ensures that it never has in its
>possession a pointer through which the string could be legally modified.

It doesn't really matter where it does the conversion since strchr() doesn't
modify the string. The problem remains however that this returns a pointer
with the const qualifier removed so that the calling function can write
through it directly. This is an example where the standard library defeats
the type system and undermines the protection that const is designed to
gives you.

As I mentioned before having strchr() return an offset rather than a pointer
would have eliminated this problem. However it would have made dealing with
match failures messier.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------